A mobile node (hereinafter, MN) using a mobile IP (Internet Protocol) requires a home agent (hereinafter, HA) for mobility management of itself. The MN notifies new location information to its HA and requests forwarding of packets destined to a home address (HoA). This HA is provided by a provider (hereinafter, a mobility service provider: MSP) to which the MN belongs and by which a mobility service is provided. Information related to the HA used by the MN is statically or dynamically configured for the MN. In the case of static configuration, there is a method of prerecording the information in the MN, or a method of allowing a user or a person on the MSP side to manually configure the information. On the other hand, in the case of dynamic configuration, it is allocated or searched for by an HA allocation request or an HA search request transmitted from the MN to the MSP side. Especially, the technique for dynamic configuration has drawn attention because the dynamic configuration allows the HA used by the MN to have more room for choice than the static configuration.
At present, the MIP6 Working Group of IETF (Internet Engineering Task Force) is considering some techniques for dynamically acquiring HA information (address of HA, etc.) based on information related to the HA previously held by the MN while minimizing the information related to the HA. Among the techniques, a so-called bootstrapping method for acquiring HA information (IP address of HA) using name resolution via a DNS (Domain Name System) is described in the following Non-Patent Document 1 as a technique used in a case where a provider providing an access service (hereinafter, access service provider: ASP) is different from the MSP (hereinafter, a split case).
Non-Patent Document 1: G. Giaretta, J. Kempf, and V. Devarapalli, “Mobile IPv6 bootstrapping in split scenario,” draft-ietf-mip6-bootstrapping-split-02.txt, March 2006.
However, provided by the technique described in Non-Patent Document 1 is a method for allowing the MN to search for HA information, and a method for allowing the provider to dynamically allocate any HA information to the MN is not shown. According to this split case technique, the MSP cannot select an appropriate HA capable of making a determination based on a connection point (location information) of the MN because the MSP does not know the location of the MN. Therefore, the MN looks up an address corresponding to HA related information (domain name of MSP, etc.) previously held by itself using an existing DNS lookup to acquire the address of an HA. In other words, the HA information that the MN can know is searched by the MN, and it is not an HA arbitrarily selected by the MSP to allocate it to a specific MN. For this reason, the MSP cannot allocate an HA appropriate for each individual MN (i.e., it cannot allocate an HA that considers location information and the like of the MN). As a result, a case can occur, where the MN cannot help using an HA existing in a location which could be disadvantageous on a route. For example, when the MN has to use an HA far from a gateway of an ASP to which the MN is being connected, the forwarding route becomes long, and this has an effect such as a packet delay. Particularly, from a world-wide standpoint, an impact caused by such an HA allocation is significant.
When an MN having plural interfaces searches for an HA from a connected interface on behalf of another interface that is not connected to an access network, the MSP cannot, of course, allocate an HA appropriate for each individual MN (i.e., it cannot allocate an HA that considers location information and the like of the unconnected interface of the MN).